"""

Dear Spenser,

Part of the reason the code has gotten so long here is because it doesn't seem as though you're splitting these functions up into enough classes.  I would suggest a base class, call it attack.  It should have a few methods, such as "draw self" or "do battle effects".  Make the functions fairly specific in what they do.  Then, have each attack be a subclass of this base attack, each its own implementation of these methods.  Or better yet, have them have the same "draw self" and "do battle effects," and supply have the parameters stored inside of the it's own class.

Let me get more concrete with this.  Let's say we had the base attack class I mentioned, I'll write a quick one below.  It probably won't work perfectly without a lot of work, as I don't completely understand how everything works right now, but hopefully you will get the idea.
"""
class Attack():
	
	def __init__(self):
		pass
	def drawAnimations(self, WhoIsAttacking, screen):
		screen.blit(self.animation.getFrame(),self.animation.getAnimationCoords)
		self.animation.advanceImage()
	def doBattleEffects(self, player,opponent):
		#note, that when this method is called, the attacking player must be set to "player" 
		raise NotImplementedError
	def paralyze(self, player, probability):
		#use this class, along with similar other ones, to do battle effects
		#set the opponent's active pokemon to be paralyzed
		player.activePokemon.paralyzed = True #I have no idea how you guys are storing the information. But the way I'm accessing it is how I would expect it to be stored.

class Thunderbolt(Attack):
	def __init__(self):
		Attack.__init__(self)
		self.animations = Animations.load("path", spriteSheetLoaderParamsForAThunderboltAttack)
		self.animations.setcoords(["<thunderbolt coords, whatever they are>"])
	def doBattleEffects(self, player, opponent):
		opponent.doDamage(self.damage) #or you might store the amount of damage in some database.  I think you guys already did that...
		Attack.paralyze(opponent, probability)

class Animation():
	def __init__(self, path, spriteSheetLoaderParameters):
		self.imageArray = loadSpriteSheet(path, spriteSheetLoaderParameters) #call whatever you need to in order to load this using your spritesheet loader"
		self.imageNumber = 0
	def getFrame(self):
		return self.imageArray[self.imageNumber]
	def getImageCoords(self):
		return self.imageCoords[self.frame]
	def advanceImage(self):
		self.imageNumber += 1
	
"""
So, hopefully you see what I mean by using more classes.  Right now, I am working on a platforming project.  We have implemented gravity, physics, projectiles, a particle system, netplay, hitboxes, animations, and probably some things I haven't thought of yet.  To do these things, we've made about 40 different classes.  No one task is done by a single class.  Making classes small and concise allows a lot of code reuse, which is a good thing.  In my own project, it allows me to, for example, create a new character type, projectile type, particle type, platform type, etc, by adding very little code.

Think about what little bits of functionality can be merged.  You may even create a battle effect class if you find you can catagorize them.  For example, you may have a base battle effect class.  It would have at least one funciton, doEffect(player, opponent).  There could then be a subclass of BattleEffect that overrides the doEffect method.  While this might be of more use in Java than in Python (because Java is strictly typed), it is worth some thought.

--Chris

P.S. Don't be afraid to put the classes in different files, too.  It'll make the project more manageable if the file names are descriptive.
"""



#''' Dear Chris,

#    Okay, i see what you mean, and i kinda understand most of it. I'll have to looks at the pygame docs to understand some things but i get most of it.
#    The main reason i was coding this way was because we integrated the 
#    cropping of the attack images into the newAttack function. we also put the drawing of the attack animations into the 
#    display function and i didn't think of changing it. But, i will try this out idea out, as it sounds a lot better and easier to use.
#    By the way, could you please tell me if the other changes in the integrating file work, because i saved a lot lines with the changes.
#    FYI, some of the changes are to things that will go into this new Attack class. 
#    
#    Thank you very much,
#    Spenser
#    
#    '''

"""

Spenser,

Could you define "work"?  And do you mean the ~500 line file, integraing_something_or_other.py?  Sorry, but I'd really rather not....  btw, do you have skype?  That'd be a much easer way to communicate.
"""
#################

''' Sorry for not being clear. In the integrating_animations_and_battlescreen.py file i went in and replaced 
    if/elif statements (3 seperate long lines of them), with for loops. I did this in an attempt to make the code shorter.
    I do have a skype account. My username-thing is spenser.solys1. Because for some reason there already is a spenser.solys.
    
    '''